<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
<meta http-equiv="X-UA-Compatible" content="IE=11"/>
<meta name="generator" content="Doxygen 1.9.4"/>
<meta name="viewport" content="width=device-width, initial-scale=1"/>
<title>Embroidermodder: Geometry and Algorithms</title>
<link href="tabs.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript" src="dynsections.js"></script>
<link href="navtree.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="resize.js"></script>
<script type="text/javascript" src="navtreedata.js"></script>
<script type="text/javascript" src="navtree.js"></script>
<link href="search/search.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="search/searchdata.js"></script>
<script type="text/javascript" src="search/search.js"></script>
<script type="text/x-mathjax-config">
MathJax.Hub.Config({
  extensions: ["tex2jax.js", "TeX/AMSmath.js"],
  jax: ["input/TeX","output/HTML-CSS"],
});
</script>
<script type="text/javascript" async="async" src="https://cdn.jsdelivr.net/npm/mathjax@2/MathJax.js"></script>
<link href="doxygen.css" rel="stylesheet" type="text/css" />
<link href="doxygen-awesome.css" rel="stylesheet" type="text/css"/>
</head>
<body>
<div id="top"><!-- do not remove this div, it is closed by doxygen! -->
<div id="titlearea">
<table cellspacing="0" cellpadding="0">
 <tbody>
 <tr id="projectrow">
  <td id="projectlogo"><img alt="Logo" src="logo_embroidermodder_2_0.png"/></td>
  <td id="projectalign">
   <div id="projectname">Embroidermodder<span id="projectnumber">&#160;2.0.0-alpha4</span>
   </div>
   <div id="projectbrief">A free and open source software for machine embroidery</div>
  </td>
 </tr>
 </tbody>
</table>
</div>
<!-- end header part -->
<!-- Generated by Doxygen 1.9.4 -->
<script type="text/javascript">
/* @license magnet:?xt=urn:btih:d3d9a9a6595521f9666a5e94cc830dab83b65699&amp;dn=expat.txt MIT */
var searchBox = new SearchBox("searchBox", "search",'Search','.html');
/* @license-end */
</script>
<script type="text/javascript" src="menudata.js"></script>
<script type="text/javascript" src="menu.js"></script>
<script type="text/javascript">
/* @license magnet:?xt=urn:btih:d3d9a9a6595521f9666a5e94cc830dab83b65699&amp;dn=expat.txt MIT */
$(function() {
  initMenu('',true,false,'search.php','Search');
  $(document).ready(function() { init_search(); });
});
/* @license-end */
</script>
<div id="main-nav"></div>
</div><!-- top -->
<div id="side-nav" class="ui-resizable side-nav-resizable">
  <div id="nav-tree">
    <div id="nav-tree-contents">
      <div id="nav-sync" class="sync"></div>
    </div>
  </div>
  <div id="splitbar" style="-moz-user-select:none;" 
       class="ui-resizable-handle">
  </div>
</div>
<script type="text/javascript">
/* @license magnet:?xt=urn:btih:d3d9a9a6595521f9666a5e94cc830dab83b65699&amp;dn=expat.txt MIT */
$(document).ready(function(){initNavTree('geometry-and-algorithms.html',''); initResizable(); });
/* @license-end */
</script>
<div id="doc-content">
<!-- window showing the filter options -->
<div id="MSearchSelectWindow"
     onmouseover="return searchBox.OnSearchSelectShow()"
     onmouseout="return searchBox.OnSearchSelectHide()"
     onkeydown="return searchBox.OnSearchSelectKey(event)">
</div>

<!-- iframe showing the search results (closed by default) -->
<div id="MSearchResultsWindow">
<iframe src="javascript:void(0)" frameborder="0" 
        name="MSearchResults" id="MSearchResults">
</iframe>
</div>

<div><div class="header">
  <div class="headertitle"><div class="title"><a class="el" href="classGeometry.html" title="The Geometry class.">Geometry</a> and Algorithms </div></div>
</div><!--header-->
<div class="contents">
<div class="textblock"><h1><a class="anchor" id="geometry-to-do"></a>
To Do</h1>
<dl class="todo"><dt><b><a class="el" href="todo.html#_todo000201">Todo:</a></b></dt><dd>(Arduino) Fix emb-outline files</dd></dl>
<dl class="todo"><dt><b><a class="el" href="todo.html#_todo000202">Todo:</a></b></dt><dd>(Arduino)Fix thread-color files</dd></dl>
<dl class="todo"><dt><b><a class="el" href="todo.html#_todo000203">Todo:</a></b></dt><dd>(Arduino) Logging of Last Stitch Location to External USB Storage(commonly available and easily replaced) ...wait until TRE is available to avoid rework</dd></dl>
<dl class="todo"><dt><b><a class="el" href="todo.html#_todo000204">Todo:</a></b></dt><dd>(Arduino) inotool.org - seems like the logical solution for Nightly/CI builds</dd></dl>
<dl class="todo"><dt><b><a class="el" href="todo.html#_todo000205">Todo:</a></b></dt><dd>(Arduino) Smoothieboard experiments</dd></dl>
<dl class="todo"><dt><b><a class="el" href="todo.html#_todo000206">Todo:</a></b></dt><dd>(testing) looping test that reads 10 times while running valgrind. See \texttt{<a class="el" href="embroidery_8h.html#a3bf191bd99e2da8d36465f454a4646f6">embPattern_loadExternalColorFile()</a>} Arduino leak note for more info.</dd></dl>
<h2><a class="anchor" id="development"></a>
Development</h2>
<p >If you wish to develop with us you can chat via the contact email on the [website]\url{<a href="https://libembroidery.org">https://libembroidery.org</a>} or in the issues tab on the [github page]\url{<a href="https://github.com/Embroidermodder/Embroidermodder/issues">https://github.com/Embroidermodder/Embroidermodder/issues</a>}. People have been polite and friendly in these conversations and I (Robin) have really enjoyed them. If we do have any arguments please note we have a [Code of Conduct] <a class="el" href="CODE__OF__CONDUCT_8md.html">CODE_OF_CONDUCT.md</a> so there is a consistent policy to enforce when dealing with these arguments.</p>
<p >The first thing you should try is building from source using the [build advice](build) above. Then read some of the [manual] \url{<a href="https://libembroidery.org/embroidermodder_2.0_manual.pdf">https://libembroidery.org/embroidermodder_2.0_manual.pdf</a>} to get the general layout of the source code and what we are currently planning.</p>
<h2><a class="anchor" id="testing"></a>
Testing</h2>
<p >To find unfixed errors run the tests by launching from the command line with: </p><pre class="fragment">$ embroidermodder --test
</pre><p> then dig through the output. It's currently not worth reporting the errors, since there are so many but if you can fix anything reported here you can submit a PR.</p>
<h2><a class="anchor" id="contributing"></a>
Contributing</h2>
<h3><a class="anchor" id="funding"></a>
Funding</h3>
<p >The easiest way to help is to fund development (see the Donate button above), since we can't afford to spend a lot of time developing and only have limited kit to test out libembroidery on.</p>
<h3><a class="anchor" id="programming-and-engineering"></a>
Programming and Engineering</h3>
<p >Should you want to get into the code itself:</p>
<ul>
<li>Low level C developers are be needed for the base library <code>libembroidery</code>.</li>
<li>Low level assembly programmers are needed for translating some of <code>libembroidery</code> to <code>EmbroiderBot</code>.</li>
<li>Hardware Engineers to help design our own kitbashed embroidery machine <code>EmbroiderBot</code>, one of the original project aims in 2013.</li>
<li>Scheme developers and C/SDL developers to help build the GUI.</li>
<li>Scheme developers to help add designs for generating of custom stitch-filled emblems like the heart or dolphi. Note that this happens in Embroidermodder not libembroidery (which assumes that you already have a function available).</li>
</ul>
<h3><a class="anchor" id="writing"></a>
Writing</h3>
<p >We also need people familiar with the software and the general machine embroidery ecosystem to contribute to the <a href="https://github.com/Embroidermodder/docs">documentation</a>.</p>
<p >We need researchers to find references for the documentation: colour tables, machine specifications etc. The history is murky and often very poorly maintained so if you know anything from working in the industry that you can share: it'd be appreciated!</p>
<h2><a class="anchor" id="embroidermodder-project-coding-standards"></a>
Embroidermodder Project Coding Standards</h2>
<p >A basic set of guidelines to use when submitting code.</p>
<p >Code structure is mre important than style, so first we advise you read `&lsquo;Design&rsquo;' and experimenting before getting into the specifics of code style.</p>
<h3><a class="anchor" id="where-code-goes"></a>
Where Code Goes</h3>
<p >Anything that deals with the specifics of embroidery file formats, threads, rendering to images, embroidery machinery or command line interfaces should go in <code>libembroidery</code> not here.</p>
<h3><a class="anchor" id="Where"></a>
Non-compiled Files Go</h3>
<dl class="todo"><dt><b><a class="el" href="todo.html#_todo000207">Todo:</a></b></dt><dd>Like most user interfaces Embroidermodder is mostly data, so here we will have a list describing where each CSV goes.</dd></dl>
<h3><a class="anchor" id="Ways"></a>
in which we break style on purpose</h3>
<p >Most style guides advise you to keep functions short. We make a few pointed exceptions to this where the overall health and functionality of the source code should benefit.</p>
<p >The <code>actuator</code> function will always be a mess and it should be: we're keeping the total source lines of code down by encoding all user action into a descrete sequence of strings that are all below \texttt{_STRING_LENGTH} in length. See the section on the actuator (TODO) describing why any other solution we could think here would mean more more code without a payoff in speed of execution or clarity.</p>
<h2><a class="anchor" id="version-control"></a>
Version Control</h2>
<p >Being an open source project, developers can grab the latest code at any time and attempt to build it themselves. We try our best to ensure that it will build smoothly at any time, although occasionally we do break the build. In these instances, please provide a patch, pull request which fixes the issue or open an issue and notify us of the problem, as we may not be aware of it and we can build fine.</p>
<p >Try to group commits based on what they are related to: features/bugs/comments/graphics/commands/etc...</p>
<h2><a class="anchor" id="Donations"></a>
Donations</h2>
<p >Creating software that interfaces with hardware is costly. A summary of some of the costs involved:</p>
<ul>
<li>Developer time for 2 core developers</li>
<li>Computer equipment and parts</li>
<li>Embroidery machinery</li>
<li>Various electronics for kitbashing Embroiderbot</li>
<li>Consumable materials (thread, fabric, stabilizer, etc...)</li>
</ul>
<p >If you have found our software useful, please consider funding further development by donating to the project on Open Collective (\url{<a href="https://opencollective.com/embroidermodder">https://opencollective.com/embroidermodder</a>}).</p>
<h2><a class="anchor" id="embroidermodder-project"></a>
Embroidermodder Project Coding Standards</h2>
<p >Rather than maintain our own standard for style, please defer to the Python's PEP 7 <a class="el" href="citelist.html#CITEREF_pep7">[3]</a> for C style and emulating that in C++.</p>
<p >A basic set of guidelines to use when submitting code. Defer to the PEP7 standard with the following additions:</p>
<ul>
<li>All files and directories shall be lowercase and contain no spaces.</li>
<li>Structs and class names should use LeadingCapitals.</li>
<li>Enums and constants should be BLOCK_CAPITALS.</li>
<li>Class members and functions without a parent class should be snake_case. With the exception of when one of the words is a "class" name from libembroidery in which case it has the middle capitals like this: <code>embArray_add</code>.</li>
<li>Don't use exceptions.</li>
<li>Don't use ternary operator (?:) in place of if/else.</li>
<li>Don't repeat a variable name that already occurs in an outer scope.</li>
</ul>
<h3><a class="anchor" id="version-control"></a>
Version Control</h3>
<p >Being an open source project, developers can grab the latest code at any time and attempt to build it themselves. We try our best to ensure that it will build smoothly at any time, although occasionally we do break the build. In these instances, please provide a patch, pull request which fixes the issue or open an issue and notify us of the problem, as we may not be aware of it and we can build fine.</p>
<p >Try to group commits based on what they are related to: features/bugs/comments/graphics/commands/etc...</p>
<h3><a class="anchor" id="comments"></a>
Comments</h3>
<p >When writing code, sometimes there are items that we know can be improved, incomplete or need special clarification. In these cases, use the types of comments shown below. They are pretty standard and are highlighted by many editors to make reviewing code easier. We also use shell scripts to parse the code to find all of these occurrences so someone wanting to go on a bug hunt will be able to easily see which areas of the code need more love.</p>
<p >libembroidery and Embroidermodder are written in C and adheres to C89 standards. This means that any C99 or C++ comments will show up as errors when compiling with gcc. In any C code, you must use: </p><pre class="fragment">/* Use C Style Comments within code blocks.
 *
 * Use Doxygen style code blocks to place todo, bug, hack, warning,
 * and note items like this:
 *
 * \todo EXAMPLE: This code clearly needs more work or further review.
 *
 * \bug This code is definitely wrong. It needs fixed.
 *
 * \hack This code shouldn't be written this way or I don't
 * feel right about it. There may a better solution
 *
 * \warning Think twice (or more times) before changing this code.
 * I put this here for a good reason.
 *
 * \note This comment is much more important than lesser comments.
 */
</pre> <h2><a class="anchor" id="ideas"></a>
Ideas</h2>
<h3><a class="anchor" id="why-this-document"></a>
Why this document</h3>
<p >I've been trying to make this document indirectly through the Github issues page and the website we're building but I think a straightforward, plain-text file needs to be the ultimate backup for this. Then I can have a printout while I'm working on the project.</p>
<h3><a class="anchor" id="qt-and-dependencies"></a>
Qt and dependencies</h3>
<p >I'm switching to SDL2 (which is a whole other conversation) which means we can ship it with the source code package meaning only a basic build environment is necessary to build it.</p>
<h3><a class="anchor" id="documentation"></a>
Documentation</h3>
<p >Can we treat the website being a duplicate of the docs a non-starter? I'd be happier with tex/pdf only and (I know this is counter-intuitive) one per project.</p>
<h3><a class="anchor" id="social-platform"></a>
Social Platform</h3>
<p >So... all the issues and project boards etc. being on Github is all well and good assuming that we have our own copies. But we don't if Github goes down or some other major player takes over the space and we have to move (again, since this started on SourceForge).</p>
<p >This file is a backup for that which is why I'm repeating myself between them.</p>
<h3><a class="anchor" id="identify-todo"></a>
Identify the meaning of these TODO items</h3>
<ul>
<li>Saving CSV/SVG (rt) + CSV read/write UNKNOWN interpreted as COLOR bug <code>#179</code></li>
<li>Lego Mindstorms NXT/EV3 ports and/or commands</li>
</ul>
<h3><a class="anchor" id="progress-chart"></a>
Progress Chart</h3>
<p >The chart of successful from-to conversions (previously a separate issue) is something that should appear in the README.</p>
<h3><a class="anchor" id="standard"></a>
Standard</h3>
<p >The criteria for a good Pull Request from an outside developer has these properties, from most to least important:</p>
<ul>
<li>No regressions on testing.</li>
<li>Add a feature, bug fix or documentation that is already agreed on through GitHub issues or some other way with a core developer.</li>
<li>No GUI specific code should be in libembroidery, that's for Embroidermodder.</li>
<li>Pedantic/ansi C unless there's a good reason to use another language.</li>
<li>Meet the style above (i.e. <a href="\url{https://peps.python.org/pep-0007/#code-lay-out}">PEP 7, Code Lay-out</a>). We'll just fix the style if the code's good and it's not a lot of work.</li>
<li><code>embroider</code> should be in POSIX style as a command line program.</li>
<li>No dependancies that aren't "standard", i.e. use only the C Standard Library.</li>
</ul>
<h3><a class="anchor" id="image-fitting"></a>
Image Fitting</h3>
<p >A currently unsolved problem in development that warrants further research is the scenario where a user wants to feed embroider an image that can then be .</p>
<h3><a class="anchor" id="to-place"></a>
To Place</h3>
<p >A <em>right-handed coordinate system</em> is one where up is positive and right is positive. Left-handed is up is positive, left is positive. Screens often use down is positive, right is positive, including the OpenGL standard so when switching between graphics formats and stitch formats we need to use a vertical flip (<code>embPattern\_flip</code>).</p>
<p ><code>0x20</code> is the space symbol, so when padding either 0 or space is preferred and in the case of space use the literal ' '.</p>
<h3><a class="anchor" id="development-to-do"></a>
To Do</h3>
<p >We currently need help with:</p>
<ul>
<li>Thorough descriptions of each embroidery format.</li>
<li>Finding resources for each of the branded thread libraries (along with a full citation for documentation).</li>
<li>Finding resources for each geometric algorithm used (along with a full citation for documentation).</li>
<li>Completing the full <code>--full-test-suite</code> with no segfaults and at least a clear error message (for example <code>not implemented yet</code>).</li>
<li>Identifying <code>best guesses</code> for filling in missing information when going from, say <code>.csv</code> to a late <code>.pes</code> version. What should the default be when the data doesn't clarify?</li>
<li>Improving the written documentation.</li>
<li>Funding, see the Sponsor button above. We can treat this as <code>work</code> and put far more hours in with broad support in small donations from people who want specific features.</li>
</ul>
<p >Beyond this the development targets are categories sorted into:</p>
<ul>
<li>Basic Features</li>
<li>Code quality and user friendliness</li>
<li>embroider CLI</li>
<li>Documentation</li>
<li>GUI</li>
<li>electronics development</li>
</ul>
<h3><a class="anchor" id="basic-features"></a>
Basic features</h3>
<ul>
<li>Incorporate <code>#if 0</code>ed parts of <code>libembroidery.c</code>.</li>
<li>Interpret how to write formats that have a read mode from the source code and vice versa.</li>
<li>Document the specifics of the file formats here for embroidery machine specific formats. Find websites and other sources that break down the binary formats we currently don't understand.</li>
<li>Find more and better documentation of the structure of the headers for the formats we do understand.</li>
</ul>
<h3><a class="anchor" id="code-quality-and-user-friendliness"></a>
Code quality and user friendliness</h3>
<ul>
<li>Document all structs, macros and functions (will contribute directly on the web version).</li>
<li>Incorporate experimental code, improve support for language bindings.</li>
<li>Make stitch x, y into an EmbVector.</li>
</ul>
<h3><a class="anchor" id="documentation"></a>
Documentation</h3>
<ul>
<li>Create csv data files for thread tables.</li>
<li>Convert tex to markdown, make tex an output of <code>build.bash</code>.</li>
<li>Run <code>sloccount</code> on <code>extern/</code> and <code>.</code> (and ) so we know the current scale of the project, aim to get this number low. Report the total as part of the documentation.</li>
<li>Try to get as much of the source code that we maintain into C as possible so new developers don't need to learn multiple languages to have an effect. This bars the embedded parts of the code.</li>
</ul>
<h3><a class="anchor" id="gui"></a>
GUI</h3>
<ul>
<li>Make EmbroideryMobile (Android) also backend to <code>libembroidery</code> with a Java wrapper.</li>
<li>Make EmbroideryMobile (iOS) also backend to <code>libembroidery</code> with a Swift wrapper.</li>
<li>Share some of the MobileViewer and iMobileViewer layout with the main EM2. Perhaps combine those 3 into the Embroidermodder repository so there are 4 repositories total.</li>
<li>Convert layout data to JSON format and use cJSON for parsing.</li>
</ul>
<h2><a class="anchor" id="electronics-development"></a>
Electronics development</h2>
<ul>
<li>Currently experimenting with Fritzing[8](8), upload netlists to embroiderbot when they can run simulations using the asm in <code>libembroidery</code>.</li>
<li>Create a common assembly for data that is the same across chipsets <code>libembrodiery\_data\_internal.s</code>.</li>
<li>Make the defines part of <code><a class="el" href="embroidery_8h.html">embroidery.h</a></code> all systems and the function list <code>c code only</code>. That way we can share some development between assembly and C versions.</li>
</ul>
<h2><a class="anchor" id="Development"></a>
Development</h2>
<h3><a class="anchor" id="Contributing"></a>
Contributing</h3>
<p >If you're interested in getting involved, here's some guidance for new developers. Currently The Embroidermodder Team is all hobbyists with an interest in making embroidery machines more open and user friendly. If you'd like to support us in some other way you can donate to our Open Collective page (click the Donate button) so we can spend more time working on the project.</p>
<p >All code written for libembroidery should be ANSI C89 compliant if it is C. Using other languages should only be used where necessary to support bindings.</p>
<h3><a class="anchor" id="debug"></a>
Debug</h3>
<p >If you wish to help with development, run this debug script and send us the error log. </p><pre class="fragment">#!/bin/bash

rm -fr libembroidery-debug

git clone http://github.com/embroidermodder/libembroidery libembroidery-debug
cd libembroidery-debug

cmake -DCMAKE_BUILD_TYPE=DEBUG .
cmake --build . --config=DEBUG

valgrind ./embroider --full-test-suite
</pre><p> While we will attempt to maintain good results from this script as part of normal development it should be the first point of failure on any system we haven't tested or format we understand less.</p>
<h3><a class="anchor" id="binary-download"></a>
Binary download</h3>
<p >We need a current <code>embroider</code> command line program download, so people can update without building.</p>
<h1><a class="anchor" id="embroiderbot"></a>
Embroiderbot and Libembroidery on Embedded Systems</h1>
<p >The libembroidery library is designed to support embedded environments, so it can be used in CNC applications.</p>
<h2><a class="anchor" id="compatible-board"></a>
Compatible Boards</h2>
<p >We recommend using an Arduino<a id="a213_Mega:202560:20or:20another:20board:20with:20equal:20or" name="a213_Mega:202560:20or:20another:20board:20with:20equal:20or"></a> greater specs. That being said, we have had success using an Arduino Uno R3 but this will likely require further optimization and other improvements to ensure continued compatibility with the Uno. See below for more information.</p>
<h2><a class="anchor" id="arduino"></a>
Arduino Considerations</h2>
<p >There are two main concerns here: Flash Storage and SRAM.</p>
<p >libembroidery continually outgrows the 32KB of Flash storage on the Arduino Uno and every time this occurs, a decision has to be made as to what capabilities should be included or omitted. While reading files is the main focus on arduino, writing files may also play a bigger role in the future. Long term, it would be most practical to handle the inclusion or omission of any feature via a single configuration header file that the user can modify to suit their needs.</p>
<p >SRAM is in extremely limited supply and it will deplete quickly so any dynamic allocation should occur early during the setup phase of the sketch and sparingly or not at all later in the sketch. To help minimize SRAM consumption on Arduino and ensure libembroidery can be used in any way the sketch creator desires, it is required that any sketch using libembroidery must implement event handlers. See the ino-event source and header files for more information.</p>
<p >There is also an excellent article by Bill Earl on the Adafruit Learning System which covers these topics in more depth: <a href="http://learn.adafruit.com/memories-of-an-arduino?view=all">http://learn.adafruit.com/memories-of-an-arduino?view=all</a>.</p>
<h2><a class="anchor" id="space"></a>
Space</h2>
<p >Since a stitch takes 3 bytes of storage and many patterns use more than 10k stitches, we can't assume that the pattern will fit in memory. Therefore we will need to buffer the current pattern on and off storage in small chunks. By the same reasoning, we can't load all of one struct beore looping so we will need functions similar to binaryReadInt16 for each struct.</p>
<p >This means the EmbArray approach won't work since we need to load each element and dynamic memory management is unnecessary because the arrays lie in storage.</p>
<dl class="todo"><dt><b><a class="el" href="todo.html#_todo000208">Todo:</a></b></dt><dd>Replace EmbArray functions with embPattern load functions.</dd></dl>
<h2><a class="anchor" id="tables"></a>
Tables</h2>
<p >All thread tables and large text blocks are too big to compile directly into the source code. Instead we can package the library with a data packet that is compiled from an assembly program in raw format so the specific padding can be controlled.</p>
<p >In the user section above we will make it clear that this file needs to be loaded on the pattern USB/SD card or the program won't function.</p>
<dl class="todo"><dt><b><a class="el" href="todo.html#_todo000209">Todo:</a></b></dt><dd>Start file with a list of offsets to data with a corresponding table to load into with macro constants for each label needed.</dd></dl>
<h2><a class="anchor" id="current_pattern"></a>
Current Pattern Memory Management</h2>
<p >It will be simpler to make one file per EmbArray so we keep an EmbFile* and a length, so no malloc call is necessary. So there needs to be a consistent tmpfile naming scheme.</p>
<dl class="todo"><dt><b><a class="el" href="todo.html#_todo000210">Todo:</a></b></dt><dd>For each pattern generate a random string of hexadecimal and append it to the filenames like <code>stitchList\_A16F.dat</code>. Need to check for a file which indicates that this string has been used already.</dd></dl>
<h2><a class="anchor" id="special-notes"></a>
Special Notes</h2>
<p >Due to historical reasons and to remain compatible with the Arduino 1.0 IDE, this folder must be called `&lsquo;utility&rsquo;'. Refer to the arduino build process for more info: <a href="https://arduino.github.io/arduino-cli/0.19/sketch-build-process/">https://arduino.github.io/arduino-cli/0.19/sketch-build-process/</a>.</p>
<p >libembroidery relies on the Arduino SD library for reading files. See the ino-file source and header files for more information.</p>
<h2><a class="anchor" id="the-assembly-split"></a>
The Assembly Split</h2>
<p >One problem to the problem of supporting both systems with abundant memory (such as a 2010s or later desktop) and with scarce memory (such as embedded systems) is that they don't share the same assembly language. To deal with this: there will be two equivalent software which are hand engineered to be similar but one will be in C and the other in the assembly dialects we support.</p>
<p >All assembly will be intended for embedded systems only, since a slightly smaller set of features will be supported. However, we will write a <code>x86</code> version since that can be tested.</p>
<p >That way the work that has been done to simplify the C code can be applied to the assembly versions.</p>
<h1><a class="anchor" id="embroider"></a>
The Embroider Command Line Program</h1>
<dl class="todo"><dt><b><a class="el" href="todo.html#_todo000211">Todo:</a></b></dt><dd>Move back to libembroidery now we have the combined docs build.</dd></dl>
<h2><a class="anchor" id="pipeline"></a>
Embroider pipeline</h2>
<p >Adjectives apply to every following noun so </p><pre class="fragment">embroider --satin 0.3,0.6 --thickness 2 --circle 10,20,5 \
    --border 3 --disc 30,40,10 --arc 30,50,10,60 output.pes
</pre><p> Creates:</p>
<ul>
<li>a circle with properties: thickness 2, satin 0.3,0.6</li>
<li>a disc with properties:</li>
<li>an arc with properties:</li>
</ul>
<p >in that order then writes them to the output file <code>output.pes</code>.</p>
<h2><a class="anchor" id="cli"></a>
embroider CLI</h2>
<ul>
<li>Make <code>-circle</code> flag to add a circle to the current pattern.</li>
<li>Make <code>-rect</code> flag to add a rectangle to the current pattern.</li>
<li>Make <code>-fill</code> flag to set the current satin fill algorithm for the current geometry. (for example <code>-fill crosses -circle 11,13,10</code> fills a circle with center 11mm, 13mm with radius 10mm with crosses).</li>
<li>Make <code>-ellipse</code> flag to add to ellipse to the current pattern.</li>
<li>Make <code>-bezier</code> flag to add a bezier curve to the current pattern. </li>
</ul>
</div></div><!-- contents -->
</div><!-- PageDoc -->
</div><!-- doc-content -->
<!-- start footer part -->
<div id="nav-path" class="navpath"><!-- id is needed for treeview function! -->
  <ul>
    <li class="footer">Generated by <a href="https://www.doxygen.org/index.html"><img class="footer" src="doxygen.svg" width="104" height="31" alt="doxygen"/></a> 1.9.4 </li>
  </ul>
</div>
</body>
</html>
